We are not steering the conversation, rather, engaging in a discussion where we are seeking a resolution that meets both our expectations. Also thank you for your thoughts and insights. Here's the way I see it: > 1. mozilla-central has an established practice of separating stylesheets (not talking about style property access) into CSS files instead of having them in style tags or embedded in scripts. There's been a long-standing issue with files growing too large over time, requiring them to be split up. Generally separating stylesheets from scripts is an easy way to better organize stuff from the start before things get out of hand. We have been doing it this way all these years, because we didn't have another choice. At one point, we bought into the promise of custom elements and they didn't deliver on that promise. Lit's reason for being is to minimize that friction we have when writing custom elements and one of those is styling. Plus, we are using lit. And lit is not the same as writing custom elements. Having big files is an issue with separation of concerns rather than having a long css string. **Long-standing code is simply code written well not organized better.** > 2. There's necessarily going to be an overlap between your team and external folks working with / maintaining your code, stylesheets in particular. Indeed, we will undoubtedly have contributions from external contributors and people from other teams. If it's a simple search and replace, then I don't see an issue with that. If it's more involved than that, then that person probably needs to inspect the html. In that case, a css string is the least of their worries. In general, anyone doing more than a search and replace must have lit knowledge, because we are indeed writing lit elements. > 3. It's not going to be a blocking a review, but the desktop-theme-reviewers group would like to have the opportunity to glance over stylesheets as they land or get modified to prevent obvious mistakes from creeping in and growing into larger problems over time. However, reviewer group tagging is based on path and file name patterns rather than file contents. This is a valid argument regarding reviews ! > 4. None of the reasons why Lit recommends inlining stylesheets seem to apply to Firefox. (From what I remember, inlining might actually be worse performance-wise as it prevents stylesheets from being shared in memory.) In fact they do. We are writing html inside Firefox. Just by the nature of how stylesheets are loaded, they are blocking ( for good reason ). And I gave a link above that mentioned FAUC. This might not be noticeable to the user, **but it is possible**. We are not using any random inlining here, we are using lit's internal mechanism. **Styles are static so they are shared by all instances of that component**. Plus, we will never get FAUC because lit will always apply the styles upon rendeing. Also if we don't have any benchmarks done on central, I would take lit's word for it. > 5. CSS linting integration with mozilla-central seems to be an unresolved issue. Again, we are using lit not just inlining css for the sake of it. Any decent linter/formatter for lit will have this baked in. I would use the same argument for html here. Should we write separate html just for linting ? > 6. The reusable components team, who I believe is now the prime user of Lit, has accepted this reality. What reality exactly are you talking about? The reusable components team is writing components for the entire browser. They have a different set of requirements than ours and need to make different tradeoffs. > please be good mozilla-central citizens and work with the status quo. I don't think there are bad and good "mozilla-central citizens" here, merely a bunch of people having a discussion on what's best for mozilla-central. The bad would not to have these discussions at all ! Hopefully, this clarifies things a bit. We are still discussing things internally.
Bug 1834533 Comment 12 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
We are not steering the conversation, rather, engaging in a discussion where we are seeking a resolution that meets both our expectations. Also thank you for your thoughts and insights. Here's the way I see it: > 1. mozilla-central has an established practice of separating stylesheets (not talking about style property access) into CSS files instead of having them in style tags or embedded in scripts. There's been a long-standing issue with files growing too large over time, requiring them to be split up. Generally separating stylesheets from scripts is an easy way to better organize stuff from the start before things get out of hand. We have been doing it this way all these years, because we didn't have another choice. At one point, we bought into the promise of custom elements and they didn't deliver on that promise. Lit's reason for being is to minimize that friction we have when writing custom elements and one of those is styling. Plus, we are using lit. And lit is not the same as writing custom elements. Having big files is an issue with separation of concerns rather than having a long css string. **Long-standing code is simply code written well not organized better.** > 2. There's necessarily going to be an overlap between your team and external folks working with / maintaining your code, stylesheets in particular. Indeed, we will undoubtedly have contributions from external contributors and people from other teams. If it's a simple search and replace, then I don't see an issue with that. If it's more involved than that, then that person probably needs to inspect the html. In that case, a css string is the least of their worries. In general, anyone doing more than a search and replace must have lit knowledge, because we are indeed writing lit elements. > 3. It's not going to be a blocking a review, but the desktop-theme-reviewers group would like to have the opportunity to glance over stylesheets as they land or get modified to prevent obvious mistakes from creeping in and growing into larger problems over time. However, reviewer group tagging is based on path and file name patterns rather than file contents. This is a valid argument regarding reviews ! > 4. None of the reasons why Lit recommends inlining stylesheets seem to apply to Firefox. (From what I remember, inlining might actually be worse performance-wise as it prevents stylesheets from being shared in memory.) In fact they do. We are writing html inside Firefox. Just by the nature of how stylesheets are loaded, they are blocking ( for good reason ). And I gave a link above that mentioned FAUC. This might not be noticeable to the user, **but it is possible**. We are not using any random inlining here, we are using lit's internal mechanism. **Styles are static so they are shared by all instances of that component**. Plus, we will never get FAUC because lit will always apply the styles upon rendeing. Also if we don't have any benchmarks done on central, I would take lit's word for it. > 5. CSS linting integration with mozilla-central seems to be an unresolved issue. Again, we are using lit not just inlining css for the sake of it. Any decent linter/formatter for lit will have this baked in. I would use the same argument for html here. Should we write separate html just for linting ? > 6. The reusable components team, who I believe is now the prime user of Lit, has accepted this reality. What reality exactly are you talking about? The reusable components team is writing components for the entire browser. They have a different set of requirements than ours and need to make different tradeoffs. > please be good mozilla-central citizens and work with the status quo. I don't think there are bad and good "mozilla-central citizens" here, merely a bunch of people having a discussion on what's best for mozilla-central. The bad would be to not have these discussions at all ! Hopefully, this clarifies things a bit. We are still discussing things internally.
We are not steering the conversation, rather, engaging in a discussion where we are seeking a resolution that meets both our expectations. Also thank you for your thoughts and insights. Here's the way I see it: > 1. mozilla-central has an established practice of separating stylesheets (not talking about style property access) into CSS files instead of having them in style tags or embedded in scripts. There's been a long-standing issue with files growing too large over time, requiring them to be split up. Generally separating stylesheets from scripts is an easy way to better organize stuff from the start before things get out of hand. We have been doing it this way all these years, because we didn't have another choice. At one point, we bought into the promise of custom elements and they didn't deliver on that promise. Lit's reason for being is to minimize that friction we have when writing custom elements and one of those is styling. Plus, we are using lit. And lit is not the same as writing custom elements. Having big files is an issue with separation of concerns rather than having a long css string. **Long-standing code is simply code written well not organized better.** > 2. There's necessarily going to be an overlap between your team and external folks working with / maintaining your code, stylesheets in particular. Indeed, we will undoubtedly have contributions from external contributors and people from other teams. If it's a simple search and replace, then I don't see an issue with that. If it's more involved than that, then that person probably needs to inspect the html. In that case, a css string is the least of their worries. In general, anyone doing more than a search and replace must have lit knowledge, because we are indeed writing lit elements. > 3. It's not going to be a blocking a review, but the desktop-theme-reviewers group would like to have the opportunity to glance over stylesheets as they land or get modified to prevent obvious mistakes from creeping in and growing into larger problems over time. However, reviewer group tagging is based on path and file name patterns rather than file contents. This is a valid argument regarding reviews ! > 4. None of the reasons why Lit recommends inlining stylesheets seem to apply to Firefox. (From what I remember, inlining might actually be worse performance-wise as it prevents stylesheets from being shared in memory.) In fact they do. We are writing html inside Firefox. Just by the nature of how stylesheets are loaded, they are not blocking ( for good reason ). And I gave a link above that mentioned FAUC. This might not be noticeable to the user, **but it is possible**. We are not using any random inlining here, we are using lit's internal mechanism. **Styles are static so they are shared by all instances of that component**. Plus, we will never get FAUC because lit will always apply the styles upon rendeing. Also if we don't have any benchmarks done on central, I would take lit's word for it. > 5. CSS linting integration with mozilla-central seems to be an unresolved issue. Again, we are using lit not just inlining css for the sake of it. Any decent linter/formatter for lit will have this baked in. I would use the same argument for html here. Should we write separate html just for linting ? > 6. The reusable components team, who I believe is now the prime user of Lit, has accepted this reality. What reality exactly are you talking about? The reusable components team is writing components for the entire browser. They have a different set of requirements than ours and need to make different tradeoffs. > please be good mozilla-central citizens and work with the status quo. I don't think there are bad and good "mozilla-central citizens" here, merely a bunch of people having a discussion on what's best for mozilla-central. The bad would be to not have these discussions at all ! Hopefully, this clarifies things a bit. We are still discussing things internally.